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Software Classification (NASA) 

Governing Document: NASA Procedural Requirements 7150.2B NASA 
Software Engineering Requirements 

NASA-Wide Software Classifications 

Class A Human-Rated Space Software Systems 

Class B Non -Human Space-Rated Software Systems or Large-Scale 
Aeronautics Vehicles 

Class C Mission Support Software or Aeronautic Vehicles, or Major 
Engineering Research Facility Software 

(e.g. t Classes A through C are mostly software developed or acquired for Highly Specialized IT systems) 

Class D Basic Science/Engineering Design and Research and Technology 
Software 

Class E Design Concept and Research and Technology Software 

Class F General Purpose Computing, Business and IT Software (Multi-Center 

or Multi- Program Project) 

Class G General Purpose Computing, Business and IT Software (Single Center 

or Project) 

Class H General Purpose Desktop Software 



Notes: It is not uncommon for a project to contain multiple systems and subsystems having different 
software classes. 
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Software Classification (AFRC) 



Governing Document: DPR-71 50.2 Armstrong Software Engineering 
Requirements 

• Software Classification (either Safety Critical “-S” or Non-Safety Critical) 

- Class I: Catastrophic 

- Class II: Critical 

- Class III: Minor (not applicable for Safety Critical Software) 

- Class IV: Negligible (not applicable for Safety Critical Software) 

• Software Criticality (determined using a Preliminary Hazard Analysis 
preformed during the system architectural development) 

- Safety Critical: any condition, event, operation, process, equipment, or system that could 
cause or lead to severe injury, major damage, or mission failure if performed or built 
improperly, or allowed to remain uncorrected. 

- Non-Safety Critical: anything that is not Safety Critical 


• Categories of requirements include the following: 


• Compliance 

• Project formulation 

• Software life cycle 

• Software plans 

• Software requirements 

• Software design 

• Peer reviews/inspections 


Software implementation 
Software testing 

Software verification and validation 
Software configuration 
Software measurement 

Software operations, maintenance, and 
retirement 
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What Are Verification and Validation? 
(... and how are they different?) 



V&V testing looks at the entire system, both software and 
hardware, as the system to be tested 


Verification 


- Proving that the system does exactly what it was designed to do 

- Follow the specification (even if that is not the right thing to do) 

Validation 


- Proving that the behavior of the system is acceptable 

Configuration control is a key element 

- Control the thing being tested, document all changes 

- Document results of all tests conducted 


Types of testing 

- Software-in-the-loop (SIL) 

- Brass-board-in-the-loop (BBIL) 

- Hardware-in-the-loop (HIL) 

- Iron-bird or airplane-in-the-loop (AIL) 
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Background 

• X-29 - SIL, HIL, AIL (Class l-S - 1984-1992) 

- Low AOA and high AOA control law development & control law 
improvements 

- XAIDS ARINC 429 bus monitor, (2) 8 channel stripchart 
recorders, limited simulation recording capability 

- (2) RC engineers required during test (pilot and stripchart 
marker) 

- (2) RC engineers reviewed test data 





X-33 - SIL, BBIL, HI! (Class l-S - never flown) 

- Lab development only, program was ended before V&V testing 
was completed 

- Hardware 1553 bus monitors & extensive recording capability 

AAW - SIL, HIL, AIL (Class l-S - 2002-2005) 



OBES, closed-loop control laws & control law improvements 

Hardware 1553 bus monitors, extensive recording capability & 
simulated PCM stream with IADS for data monitoring 

Initially (1) RC engineer required during test and (2) RC engineers 
for review 


- Changed to (3) RC engineers for test and real-time review (except 
for time history and frequency responses which required post test 
analysis) 5 





X-29 No. 2 Software Testing Team/Sched 

• Team 

- Flight Systems 

• D. McBride, M. Earls, L. Ramey, J. Sitz, M. Thomson, and T. Vernon 

- Flight Controls 

• B. Clarke, F. Webster, J. Bauer, M. Brenner, J. Burken, and J. Ellinwood 

- Simulation Engineering and Tech Support 

• M. Pickett, D. Logan, and D. Simon 

- Pilots 

• S. Ishmael, D. Purifoy, R. Smith, and R. Wormer 

• Schedule 

- BLK-IX-AA-00 (approximately 28 weeks for testing and reviewing data) 

• Started March 9, 1989 - Finished September 28, 1989 

- BLK-IX-AA-01 (approximately 5 weeks for testing and reviewing data) 

• Started February 22, 1990 - Finished March 27, 1990 

- BLK-IX-AA-02 (approximately 4 weeks for testing and reviewing data) 

• Started November 15, 1990 - Finished December 11, 1990 
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A AW Phase I Software Testing Team/Sche 

• Team 

- Flight Systems 

• J. Baca, M. Earls, P. Gonia, and T. Quach 

- Flight Controls 

• B. Clarke, M. Allen, R. Dibley, and B. Reed 

- Simulation Engineering and Tech Support 

• M. Pickett, G. Patterson, and L. Kelly 

- Pilots 

• D. Ewers & D. Purifoy 

• Schedule 

- Phase I (approximately 30 weeks for testing and reviewing data and 8 weeks 
for fixing hardware) 

• Started November 27, 2001 - Stopped December 3, 2001 

• Fixed problems with simulation hardware 

• Re-started February 6, 2002 - Stopped March 14, 2002 

• Reviewed post-test data 

• Repeats July 22, 2002 - Finished September 12, 2002 
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A AW Phase II Software Testing Team/Sc he 

• Team 

- Flight Systems 

• J. Baca, M. Earls, F. Reaux, T. Quach, and E. Becker 

- Flight Controls 

• B. Clarke, M. Allen, R. Dibley, J. Gera, J. Hodgkinson, C. Diebler, 

I. Anchondo, and A. Matuszeski 

- Simulation Engineering and Tech Support 

• M. Pickett, G. Patterson, and L. Kelly 

- Pilots 

• D. Ewers & D. Purifoy 

• Schedule 

- Phase II (approximately 6 weeks for testing 4 weeks for fixing software) 

• Started August 1 1 , 2004 - Stopped August 27, 2004 

• Fixed problem with transient free switches and rudder trim gain 

• Re-started October 4, 2004 - Finished November 5, 2004 

- Phase IIA (5 days) 

• Started March 18, 2005 (Friday) - Finished March 24, 2005 (Thursday) 
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Software Development Role 



• Develop flight control system design 

- Normal control system (or backup) 

• Everything - “The whole enchilada”, ex. X-56A: J. Schaefer 

• New portion of the flight envelope (such as high angle of 
attack), ex. X-29 No. 2: R. Clarke/F. Webster 

• Limited scope update to existing control laws (usually to fix a 
problem or optimize the control response) 

- Specialized research control system 

• Research Flight Control System (RFCS) - may or may not be 
safety critical, ex. AAW: R. Dibley, et. al. 

• Quicker updates to the control laws typically allowed, 
especially if the control system is not safety critical 



Software Testing Role 
• Assist in the development of the test matrix 

- Help to choose the flight conditions for testing 

- Pick flight conditions that have been shown to have 
small margin(s) or would otherwise exhibit the most 
critical response(s) 

- Provide assessment of Failure Modes and Effects 
Test (FMET) test points and relationship to critical 
flight conditions 

- Assist in the development of piloted simulation test 
plans, execution, and data analysis 
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X-29 AIL Tests 



National Aeronautics and 
Space Administration 

Ames Research Center 
Dryden Flight Research Facility 
P.0. Box 273 

Edwards, California 93523-5000 


NASA 


REPLY: OFV/RC July 6 , i 989 

TO: OFF/X-29 Systems Engineer 


FROM: OFV/X-29 Controls Engineer 

SUBJECT: X-29 Number Two Block IX Ground Test Requirements 


An informal meeting was held to discuss tests which should be performed using X-29 ship 
two airplane-in-the-loop simulation. The results of these discussions are summarized below: 

• SID steup and calibration - Hook the simulation to the airplane and calibrate the 
various systems. (2 or 3 days) 

• Limit cycle tests — These tests should be simulated at low dynamic pressure and 1 gee 
straight and level condition. At most, two flight conditions should be checked (25 and 
35 degrees angle-of-attack and 25,000 feet altitude). The tests should be conducted in 
all axes and should be run to 6 db or limit cycle to verify margins. These tests should 
also be conducted on the landing gear. These are the only type of vibration tests 
which are required to be run. No ground vibration tests using soft support systems 
are required by the Structural Dynamics Group. (1 day) 

• Hydraulic model verification - This series of tests should verify flow rates under lim- 
ited flow conditions of the combined and flight systems. It should also show system 
behavior under conditions of depleted accumulators. (3 days) 

• Actuator frequency responses - Actuator frequency responses should be run. Ana- 
log breakout boxes and SID should both be used. Loaded vs. unloaded and small 
amplitude vs. large amplitude should be investigated. (1 day) 

• Piloted simululation — Run some piloted simulation of spins, departures, and high 
angle-of-attack rolls. (1 day) 

• Time history checks - Conduct time history against the hardware-in-the-loop and 
linear predictions. (1 day) 

• Frequency response checks - Conduct open and closed checks against hardware-in- 
the-loop and linear predictions. (3 days) 

• Test spin lights and frequency response of the a vanes - These tests would be used as 
filler to be run when the computer system is down due to problems, (no additional 
time) 
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Robert Clarke 


cc: Mike Earls 
Mike Thompson 
Marlin Pickett 
Todd Vernon 
Jeff Bauer 
Marty Brenner 
John Burken 
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AAW Design Test Points 
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Software Testing Role 

• Assist in verification testing (particularly for the 
control law parts of the system) 

- Verified the AAW Control Law Design Description 
(CLDD) text against the CLDD block diagrams 

- Verified Matrix-X block diagrams against the AAW 
CLDD block diagrams 

- Verified that each control system Configuration 
Change Request (CCR) had been implemented 

- Participate in AAW code walk-thru of the Phase II 
Matrix-X autocoded Ada control laws (comparison 
against CLDD) 

- Documented in a Code Inspection Issue log 
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Software Testing Role 

• Assist in development of analysis tools (if new 
ones are needed) 

- Modified generic linearizer to work on X-29 project (X-29 
1983) 

- Incorporated FFT and getData I/O routines into Fortran 
“Classic” MATLAB to compute frequency response from 
simulation data files (X-29 1988) 

- Built stand-alone program, called “getdiff”, to compare 
getData files (X-33 1997) 

- Built MATLAB routines to decode 1553 bus messages 
(AAW2001) 

- Incorporated IADS displays into sim lab and developed 
special displays (AAW 2004) 
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Software Testing Role (Continued) 

• Assist in assessment of the fidelity of the aircraft 
simulation(s) and help make improvements 

- Assess the fidelity of individual simulation model(s) 

• Compare with hardware test data (if available) 

• Compare with independent models 

- Assist in the development of higher fidelity model(s) as required 

• Provide actual code or block diagram implementation 

• Provide check cases 

• Provide model dispersion data (if required) 

• Review check case comparisons and sign STR’ s 
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Simulation Model Assess/Update/T est 

• X-29 

- Flight control system 

- Actuators - hydraulic system 

- Sensors - air data 

- Miscellaneous - mass properties & inlet ram drag 

• X-33 

- Flight control system 

- Actuators - EMA & pneumatic 

- Miscellaneous - gravity, geodetic, mass properties, landing gear model 

• AAW 

- Flight control system 

- Actuators - hinge moments 

- Sensors - air data probes 

- Miscellaneous - air data computer, aerodynamic model 
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Software Testing Role (Continued) 

• Compare time history and frequency response 
data (verification testing) 

- Generate the independent data (usually from 
MATLAB or Matrix-X) 

- Collect the hardware-in-the-loop simulation data and 
plot along with simulation results 

- Review and interpret results 

- Provide assessment in writing of the results 
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Software Testing Role (Continued) 



• Provide the piloting function during all aspects of testing 
(validation testing) 

- This allows the systems engineer to concentrate on verification 
of the proper test results 

- It provides the flight controls engineer an opportunity to see first- 
hand the airplane response (from the pilot’ s point of view) 

- The flight controls engineer shall assess the airplane response 
and validate that the response is proper and correct 

• Subjective assessment 

• Look for things that don’ t “feel right” 

• Write DR’ s as required if problems are found in the simulation 

- Recognize limits on piloting ability and call in “real pilots” as 
required 

- Provide assessment in writing of significant deviations from the 
“expected response” 


19 



Software Testing Role (Continued) 

• Assist in fixing problems in the FCS as required 

- Discover 

- Understand 

- Design 

- Analyze 

- Implement (This one is done by the flight systems 
engineers!) 

- Test 
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Software Testing Role (Continued) 

• Sign off on individual V&V STR’ s 

- Is the airplane “Safe to Fly” with the Flying Qualities 
(not Handling Qualities) that have been seen in the 
simulation? 

- Have new Hazards been identified? Are any of the 
hazards worse than previously thought? 

- Are piloting aids (LSPI), warning indications (aural 
tone), and procedures adequate? 

- Are additional ones needed or does the design 
require changes? 
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X-29 System Test Report 
and Test Procedures 



NASA 


National Aeronautics and 
Space Administration 
Ames Research Center 
Dryden Flight Research Facility 


SYSTEM TEST 
REPORT 




March 2, 1989 

SYSTEM TEST REPORT 

Page 2 

FMET-SF1 



1 . Trim the aircraft for level flight at 0.59/5000 ft., gear up, ACC, Digital Normal mode 
(switch to center). 


a. Perform a 2-G turn 

b. Fail Ch A primary pitch gyro to +1 0 volts (SIBLINC 07) T 

c. Observe FS/CP SENSOR A light on 

d. Remain in 2-G turn 

e. Fail Ch A backup pitch gyro to +1 0 volts (SIBLINC 08) ^ 

f. Observe FS/CP SENSOR A and AR A lights on 

g. Reset 


-J OVOtf * 

2. Trim the aircraft for level flight at 0.95/20K, gear up, ACC, AR mode, UA gains 


a Perform a 2-G turn 

b. Fail Ch B backup pitch gyro to +1 0 volts (SIBLINC 10) 

c. Observe FS/CP SENSOR B and AR B lights on * 

d. Reset 


r 

3. Trim the aircraft for level flight at 0.95/20K, gear up, ACC, Normal mode (switch to 
center). 


a Perform a 2-G turn 

b. Fail the Ch B primary pitch gyro to +1 0 volts (SIBLINC 09) 
c Observe FS/CP SENSOR B light on \f 

d. Continue 2-G turn 

e. Fail Ch B backup pitch gyro to +1 0 volts (SIBLINC 1 0) 

f. Observe FS/CP SENSOR B and AR B lights on ✓" 

g. Continue 2-G turn 

h. Fail the Ch C primary pitch gyro to +1 0 volts (SIBLINC 1 1 ) 

i. Observe FS/CP SENSOR A. 

SENSOR EL SENSOR 0, AR B lights on 1^ 

j. Reset 


- 

4. Trim the aircraft for level flight at 0.25/1250 ft., gear up, ACC, Digital Normal mode 
(switch to center) RAV to ADI needles engaged. 


a. Perform a normal approach 

b. Fail Ch C primary pitch gyro to +1 0 volts (SIBLINC 1 1 ) 

c. Observe FS/CP SENSOR 0 light on \T 
d Remain in normal approach 

e. Fail Ch C backup pitch gyro to +10 volts (SIBLINC 12) 
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AAW System Test Report 
and Test Procedures 




National Aeronautics and 
Space Administration 

Dryden Flight Research Center 


System Test Report 


Project: 

AAW Phase 1 1 A 


Title: 

Quad Sensor Failures at Flight Conditions 6, 14, 15 and 17 


Originator/Org.: 

Release: 

System Configuration: 

C.I.: 

Thang Quach / RF 

RFCS 4.1.3,4.1.4,4.15 

F/A-18 HILS 

2B 

OCR No.: (Ref) 

DR No.: (Ref) 

PCN No.: (Ref) 

Work Order No.: 

N/A 

N/A 

N/A 

N/A 


Objective: 

Conduct small subset of HILS FMET at flight conditions where gains were modified in RFCS Version 4.1.3 


Date: STR No: 

3/18/2005 FM-1 7.5.2. 1-1 


Cont'd on page: 

Test Setup: 

See attached procedure: FMET-17.5.2.1-1 


Cont'd on page: 

Summary Results: 7Zr#7>r/> oat l 


Cont'd on page: 

no +ransi‘e/>'b 


Si9na,ure: ^ 

Date; 

Z/z-8/oS 

Reviews. 

Date: 

DR Issued Q Yes [X] No 

Retest Required Q Yes No 

DR No.: 

DR Date: 


Remarks: 


CCB Official: 


Date: 


CCB Official: 


Date: 


DFRC 11 (05/2002) 


Page 1 


Previous versions are obsolete. 



PROJECT 

TITLE 

DATE 

STR NO. 

AAW 

FMET: Quad Sensor Failures @ Gain Index 6 

June 29, 2004 

FMET- 

17.5.2.1.6 


Test Setup (Continued from STR cover sheet) 

Note: to perform all steps under one script, run script /sim/aaw/PII_Scripts/FMET/Quad_Sensors/17.5.2.1.6 

1. Perform or verify AAW Simulation Start-Up Procedure (Required only at simulation start-up). 

2. Single yaw rate hardover failure with RFCS Armed. Verify RFCS disengages. (ID 17.5.40.1.1) 

A. (Run script /sim/aaw/PII_Scripts/FMET/Quad_Sensors/17.5.2.1.6s2) 

B. At note display, 

1. Verify gain index = 6 

2. Arm RFCS 

3. Trim throttles 

C. Depress Pause Script button to go to operate, start recording and insert failure at time two 
seconds 


D. Fly straight and level 

1. After approximately 2 seconds verify the following failure indications 
Yaw CAS "X" - Channel 1 ^ 

BLIN 424 - Channel 1 ^ 

BLIN 440 - Channel 1 (not required) ‘ — " 

RFCS disengages (de-arms) 4-^ 

M17, W31 (Not Arm Reasons) indicates Quad Sensor Failure ^ 

E. Depress Pause Script button to reset the sim, and remove and clear FCS failures 

NOTES: f) {<- 



COMPLETED BY: 

DA TEi II 

Test Conductor 


yn/ojC [ 

Test Director 

W7/1 

1 


3. Dual hardover pitch rate failures while RFCS Engaged. Verify RFCS disengage. (ID 17.5.40.1.2) 

A. (Run script /sim/aaw/PII_Scripts/FMET/Quad_Sensors/17.5.2.1.6s3) 

B. At note display, 

1. Verify gain index = 6 

2. Arm and Engage RFCS 

3. Trim throttles 

C. Depress Pause Script button to go to operate, start recording and insert failures at times five and 
ten seconds 

2 


3 
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Story Time 

• Some examples of simulation model updates 

- X-33 mass properties model 

- AAW aerodynamic model update 

• Some examples of problems found in previous tests 

- Undetected dual null roll-rate gyro failure leading to loss of 
control (X-29) 

- Air data within tolerance failures leading to control system 
instability (X-29) 

- Data anomalies in HIL (F/A-18 AAW) 

- Aerodynamic instability due to highly nonlinear pitching 
moment (F/A-18 AAW) 

- Not so transient free switches (F/A-18 AAW) 
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X-33 Mass Properties Model 



• Tank designers 
(Structures) provided 
model in terms of pitch 
and roll attitude 

• Needed to translate 
from static attitude based 
model to dynamic 
acceleration based model 

• Model did not include 
slosh dynamics 
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AAW Aerodynamic Model Update 

• AAW aerodynamics needed to be updated at the 18 
flight conditions which would be tested with new 
control law designs 

- In-flight PID results showed substantial error in some aero 
coefficients when compared with Boeing baseline 

- Needed aero model update for control law design, not just 
for a report 

- Needed simulation to match small PID inputs and larger 
amplitude maneuvers 

- Previous SRA aero model update (Phase 0) used only 
small PID maneuvers and utilized CPT measurements of 
control surface positions 

- As part of Phase II activity an AAW Aerodynamic Model 
Sensitivity Analysis/Failure Analysis report was produced 
examining the NASA design using Monte Carlo methods 26 




F/A-18 AAW Control Surfaces 





AAW OBES Pitch Doublets 
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AAW OBES Roll Doublets 
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AA W Aileron Details 
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A AW Aileron Flexibility 
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X-29 Undetected Dual Null Roll Rate Gyro 
Failure Leading to Loss of Control 

• RF engineer identified that dual roll rate gyros failed to 
null results in loss of roll rate feedback resulting in 
unacceptable roll PIO (1984) 

• Carried as a Cat I/D hazard by the X-29 program until 
July 1990 when the project desired to fly to the Dayton 
and Oshkosh airshows for static display (flight without 
control room monitoring) 

• In-flight incident with failed roll rate gyro was still on 
everyone’ s mind (so no pushback on the probability 
estimate of the hazard would be allowed) 

• Severity had to be reduced or airshows were out 
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What We Discovered 



• The problem was caused by loss of roll rate feedback and the 
forward-loop integrator (With no feedback, pilot control changes 
from rate command to acceleration command!) 

• Once this was known, a fix was possible (using only procedures) 

- Pilot could recognize the problem with (3) sensor lights, (3) AR 
lights, degraded normal indications, and horrible flying qualities in 
the roll axis 

- Without roll rate feedback the AHRS analytic monitor would not 
track and AHRS would be failed 

• Without AHRS speed stability will no longer engage 

• No speed stability will affect the landing, but simulation still 
showed 15 knot crosswind was still no problem 

- Pilot needed to select TW 9 and get his airspeed below 300 knots 

- Get wings level and stay out of the loop until airspeed dropped 
below 300, where the forward-loop integrator drops out 

- At that point the control reverts to rate command again 
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Degraded Normal 
Indication 


X-29 Cockpit (Ship No. 2) 
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X-29 Air Data Within Tolerance 
Failures and Control System Instability 



m | National Aeronautics and 

| \J/ Vj/ \ Space Administration 


Ames Research Center 

''“'yden Flight Research Facility 


DISCREPANCY REPORT (DR 

SOFTWARE/HARDWARE CONTTROL MANAGEMENT 


. ROJECT: 
X-29A 

ORIGINATOR/ORG: 

JOEL SITZ / HI 

SITE: HARDWARE-IN 
LOOP SIMULATION 

DATE & TIME OF DISC 
07/27/88 9:00PM 

DR. NO. 

283 

S VEHICLE 
□CONTROL ROOM 
0 SIMULATION 
□ OTHER 

A/C FACILITY: 

A/C S/N: 

-LT NO OR TEST NO(S) 

CRITICALITY 

/ 

ASSIGNED TO: 

K.CJrlAk. 

OTHER 

PART NAME 
BLK-VIII-AD&AE 

PART NO 

SERIAL NO 

Cl NO. (SYSTEM): 
3 


SINGLE POINT AIRDATA FAILURE 


DI SCRE PA NCY ; 


DURING V&V TESTING OF THE NEW BLK-VIII-AE SOFTWARE RELEASE A SINGLE FAILURE 
TO NULL OF THE DIGITAL QC INPUT (HADS) RESULTED IN LOSS OF CONTROL OF AIRCRAFT. 
THE V&V TEST BEING RUN AT TIME OF FAILURE WAS SF 10,11,12 AT .6/1 5K. THE 
SAME FAILURE OCCURRED WITH THE BLK-VIII-AD RELEASE. THE .6/1 5K WAS A NEW STEP 
ADDED TO TEST GAIN CHANGES FOR BLK-VIII-AE. 
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X-29 Air Data Within Tolerance 
Failures and Control System Instability 



Chronology 

• July 11, 1984- DR002 

- Undetected null second P T fail caused limit cycle at 0.59/5K. Trip level 9.8 in.Hg. 

• October 1 984 

- Changed trip level to 5.0 in.Hg. and the system passed the tests 

• December 14, 1984 - First flight 

• February 1986 - CCR148 (Flight 38) 

- Large sideprobe errors, f(M,a,|3), caused selection of sideprobes for gain 
scheduling which resulted in reduced transonic stability margins 

- Logic was changed to compare the noseboom against the selected mid value 
and choose the noseboom value if it was “ok” (within tolerance of this mid 
value), otherwise use an average of the sideprobes 

• July 27, 1988 - DR283 

- Single failure to null of noseboom air data causes loss of control 

• August 17, 1988 - CCR446 

- Add bias of 1 .5 in.Hg. To sideprobe corrected measurements of P T 

- Change P s trip level to 1.5 in.Hg. (from 2.5 in.Hg.) 

- Change P T trip level to 2.0 in.Hg. (from 5.0 in.Hg.) 
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X-29 Air Data Configuration 
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X-29 Typical Pitch Axis Bode Plot 
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X-29 Flight Test Data 



This is about -0.3 in.Hg., but worst case was found to be 1.3 in.Hg. 
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X-29 Baseline Pitch Axis Gain Margin 
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X-29 Air Data Sensitivity Analysis 

AQ C = -1.5 in.Hg. High Frequency Gain Margin 
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X-29 Air Data Sensitivity Analysis 

AQ C = +1.5 in.Hg. Low Frequency Gain Margin 




42 




X-29 Air Data System 

What We Found Out Several Years Later 



X-29 No. 2 Flight 107 13:06:05.500 a=9.7°, |3=0° M=0.294 
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AAW Data Anomalies in Phase I HIL 
RC Engineer's Record Book Entries 
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AAW Data Dropouts in the High-Speed 
Fiber-Optic Simulation to Hardware Interface 

Nuisance at first which grew to “Must fix before testing can continue!” 


f o o o 


[X! XPIot - PlotWindow 


r ooo 


1X! XPIot - PlotWindow 



0.00 10.00 20.00 

TIME (00: 00: 00. 0063) TIME <00: 00: 00. 0063) 


30.00 40.00 



File=o02_gnd. u3; Signal Suf f ix=Inone] ; Date=Cnone] 


DLHTD 

DRHTD 




0.0 20.0 

TIME(00:00:00.0125) 


40.0 60.0 80.0 100.0 



0.0 20.0 40.0 60.0 

TIME (00: 00: 00. 0125) TIME <00: 00: 00. 0125) 


80.0 100.0 




TIME (00: 00: 00. 0125) TIME<00:00:00.0125) 
File=aawsub_val_04.u3; Signal Suf f ix=Cnone] ; Date=Cnone] 
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A A W Phase II Transient Free Switch 
RC Engineer's Record Book Entries 
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A AW Transient Free Switch 
Block Diagram 


701 TEF 

cmd 
► 

TFS #1 



Z1 


20 Hz ! 80 Hz 

i 
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Not-So-Transient Free Switch 



• Let XI be the input prior to switching, X2 be the input after switching, T F is 
the transition time in seconds, t is the time in seconds, and t = 0 at the time 
of switching 


Let Z be the output and A = XI -X2 at the time of switching (A shall remain 
constant after switching) 

Z = { X2 + A(1-t/T F ); t < T f XI 


X2; 


t>T F } 



Made up <1 als* TFS1 = 5st 
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A AW 20 to 80 Averager 

• Let X n be the current input, X n _., be the previous input and A = (X n -X n _.,)/4, at 
20 Hz 

• Let the current output, Y n = Y n _<, + A, at 80 Hz 
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Second Transient Free Switch 



• Let XI be the input prior to switching, X2 be the input after switching, T F is 
the transition time in seconds, t is the time in seconds, and t = 0 at the time 
of switching 


Let Z be the output and A = XI -X2 (XI shall remain constant from the time 
of switching, but X2 can vary) 

Z = { X2 + A(1-t/T F ); t < T f X ' 


X2; 


t>T F } 



Made up data TFS2 — 5sec 
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AA W TFS Model Response Compared 

with Sim Lab Results 



FMET 1 7.5.71 .1 .1 TFS1 = 5sec TFS2 = 1 sec 
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AA W TFS Model Response Compared 

with Sim Lab Results 
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AA W TFS Model Response Compared 

with Sim Lab Results 



FMET1 7.5.71 .1.1 TFS1 = 5sec TFS2 = 4.5sec 
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Discussion 


• Questions 

• Comments 
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